비즈니스가 성장하고 혁신이 이루어짐에 따라, 비즈니스를 지원하는 IT 시스템 역시 발전하게 된다. 이 과정에서 시스템의 복잡성은 기하 급수적으로 증가한다. 

로버트 글래스는 그의 저서 ˝소프트웨어 공학의 사실과 오해˝에서 문제의 복잡성이 25% 증가하면 솔루션의 복잡성은 100% 증가한다고 이야기 하였다. 이는 예전에 비해 매우 복잡해진 현대의 비즈니스 환경에서, IT 시스템이 얼마나 복잡해 질 것인지를 개략적으로 느낄 수 있는 말이라 하겠다. 

이렇게 시스템이 복잡해 짐에 따라 소프트웨어 솔루션의 품질을 높이고 버그를 줄이는 일은 지극히 어려운 일이 되었다. 또한 이러한 문제를 풀기 위한 다양한 방법이 논의되었는데, 그 중의 하나가 바로 단위 테스트이다.

단위 테스트의 기본 원칙은 프로그램의 각 요소들을 분리하여 테스트 케이스를 만든다. 그 후 각 단위를 테스트하여 해당 요소가 정상 동작하는 것을 확인하는 것이다. 이를 통해 개발자는 코드의 리팩토링과 같은 변경 사항이 일어나더라도 개별 요소가 여전히 정상 동작하는지 쉽게 파악 할 수 있다. 또한 여러 요소가 통합 될 때 구성 요소들이 기본적으로 정상 동작함을 이미 알고 있기 때문에 상당 부분의 불확실성을 제거 할 수 있다. 

참고로 이야기 하면 단위 테스트의 한계를 명확히 이해하는 것 역시 중요한 일이다. 단위 테스트는 모든 오류를 잡을 수는 없는데, 그 이유는 오류 중 35%는 로직이 누락되어 발생하는 경우이며, 40% 정도는 단위의 조합에 의한 오류이기 때문이다(Glass, Robert L. 1981. ˝Persistent Software Errors˝ IEEE Transactions on Software Engineering, Volume7, Number2, Mar.). 이러한 오류들은 단위 테스트 만으로는 잡을 수 없고 통합 테스트 및 코드 인스펙션 등을 거쳐야 한다.